REMARKS 

Applicant respectfully requests reconsideration of this Application in light of the 
foregoing amendments and the following remarks. In a first Office action mailed 
11/03/2005, claims 1-15 were pending. Claims 1-15 were rejected as anticipated by US 
5,455,926 (Keele). Claim 14 was objected to and stated as allowable if rewritten in 
independent form. Accordingly, Applicants amended claim 14, cancelled the remaining 
claims without prejudice and requested the Application be passed to issuance. 

In a second Office action mailed 05/12/2006, however, the allowability of claim 
14 was withdrawn and claim 14 now stands rejected as anticipated by US 
2004/0098244 (Dailey). In view of the examiner's change in position on claim 14, 
Applicants have canceled claim 14 and added new claims 16-24. Support for these 
new claims is provided by previously canceled claims 1-15 and by Applicants' 
specification and figures, as noted below. 

For ease of reference, Applicants patentably distinguish these new claims from 
Keele and Dailey with respect to the rejections asserted in both the first and second 
Office actions. All references below are to the first Office action unless specifically 
stated as "second Office action." 

In General 

Conventional sequential stackers are well-known for automatic data back-up and 
retrieval applications. A conventional sequential stacker has a tape drive, tape 
cartridge slots and a robotic mechanism that moves tapes between the slots and the 
tape drive. Unlike a tape library, a stacker's robotic mechanism autoloads tape 
cartridges between the tape drive and the tape cartridge slots in a predetermined 
sequential order. In this manner, many automatic backup events are addressed, rather 
than daily, by a once weekly or longer operator action of unloading/loading the cartridge 
slots with tape cartridges. By reducing the frequency of human involvement, the 
sequential stacker eliminates the opportunity for human error or neglect. The 
sequential stacker described above utilizes physical tape cartridges loaded into a 
physical tape drive. Applicants' claims, discussed in detail below, are to a virtual tape 
stacker having, for example, a plurality of virtual tape volumes that are sequentially 
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loaded/unloaded into a virtual tape drive. Keele and Dailey do not disclose or describe 
a conventional sequential stacker, much less a virtual tape stacker. 

Keele describes a controller that emulates a single type of tape storage (IBM 
3480) having an optical disk jukebox. In particular, Keele describes a mechanism 
whereby physical storage media (optical disks) are loaded into physical drives under 
host server or operator control. Dailey also describes a physical media (data 
cartridges) that house either tape or non-tape storage media. The data cartridges plug 
into a physical device (controller) call a tape drive emulator. Keele describes a 
structure (Fig. 5) for defining multiple virtual tapes on an optical disk. Dailey does not 
teach or disclose virtual tape volumes, i.e. Dailey describes a data structure only 
suitable for managing a single "tape volume" within each data cartridge. This is not 
surprising as the Dailey data cartridge is intended to appear as a convention data tape 
cartridge (physical tape volume). See Dailey paragraph [0043]. 

Neither Keele nor Dailey disclose or describe a virtual tape drive that loads and 
unloads virtual tape volumes. Keele's virtual tapes are loaded in mass via optical disk 
into a physical optical disk drive. Dailey teaches a single physical tape volume (data 
cartridge) that loads into a physical controller (tape storage emulator) and may have 
sequential tape data stored on random access media, such as a hard disk drive. 

As such, the first and second Office actions both fail to distinguish virtual storage 
media from physical storage media and virtual tape drives from physical media drives 
and controllers. That is, neither Keele nor Dailey read on a virtual tape stacker that, for 
example, sequentially autoloads virtual tape volumes into a virtual tape drive in 
response to eject commands. 
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Claim Rejections - 35 USC § 102 

FIGS. 4, 6 & 8A-B from the Application are reproduced below to illustrate claim 
aspects that overcome the rejections cited above and distinguish the art of record. 
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Claims 16-18 



Claim 16 cites: 

A virtual tape stacker comprising: 

a server interface 410 adapted to communicate with a server; 
a random access data storage device 330; 

a data path 450 adapted to communicate with the random access data 
storage device; and 

a controller 400 configured to transfer data between the server interface 
and the random access data storage device via the data path, 

wherein the controller manages the data on the random access data 
storage device as a plurality of virtual tape volumes 500, 

wherein the controller defines a virtual tape drive (FIG. 8B) for 
transferring data between the server and the virtual tape volumes, and 

wherein the controller defines a sequential order 820 for loading the 
virtual tape volumes into the virtual tape drive, and 

wherein, in response to an eject command from the server, the controller 
unloads one of the virtual tape volumes from the virtual tape drive and loads a 
next consecutive one of the virtual tape volumes into the virtual tape drive 
according to the sequential order. 

Reference numerals added with respect to FIGS. 4, 6 and 8A-B, reproduced above. 

Keele does not disclose a sequential order for loading virtual tape volumes into a 

virtual tape drive nor loading a next consecutive virtual tape volume in response to an 

eject command . The Specification describes a tape stacker: 

As shown in FIG. 8A, a virtual sequential stacker 800 has multiple virtual 
tape volumes 500 organ ized in a sequential order 820 . The first virtual tape 
volume 812 is automatically "mounted" into the virtual tape drive by default. 
Once a virtual tape volume 500 is mounted, it behaves and operates as if it was 
loaded in a conventional tape drive. If the application program 130 (FIG. 3) 
unloads a virtual tape volume 500. the next consecutive virtual tape volume 500 
is automatically loaded . 

Specification paragraph [0034], emphasis added. 

With respect to canceled claim 1 , the Office action equates sequentially-ordered 
virtual tape volumes with "sectors which can be written and read sequentially." Office 
action page 4, paragraph 8. This confuses physical media (optical disk sectors) with 
virtual media (virtual tape volumes). Further, the Office action equates loading a next 
consecutive virtual tape volume with "the jukebox mounts or dismounts the disks into 
the optical drives." Office action page 5, paragraph 8. This confuses loading a physical 
drive (jukebox) with loading a virtual drive. As discussed above, Keele does not 
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disclose or describe a virtual tape drive construct, much less a virtual tape drive that 
sequentially loads virtual tape volumes. Accordingly, claim 16 patentably distinguishes 
Keele. 

Similarly, claim 16 patentably distinguishes Dailey, which also merely discloses 
physical media (data cartridge) loaded into a physical controller device termed the tape 
drive emulator 6 (Dailey Fig. 1). As discussed above, Dailey does not disclose a 
plurality of virtual tape volumes, but rather random access tape data stored within a 
physical data cartridge intended to appears as single tape cartridge volume, such as 
the "9490EE magnetic storage tape cartridge . . ." Dailey paragraph [0043]. As such, 
Dailey does not disclose a virtual tape drive or a plurality of virtual tape volumes, much 
less a virtual tape drive that sequentially loads virtual tape volumes. 

Claims 17 and 18, which depend from claim 16 are likewise not anticipated by 
Keele or Dailey. Claims 17 and 18 are not anticipated by Keele or Dailey for the 
additional reasons discussed immediately below. 



Claim 17 cites: 

The virtual tape stacker according to claim 16 further comprising: 
a volume management table 601 residing on the random access storage 

device and accessible by the controller, the volume management table having 

pointers 620 to the virtual tape volumes; and 

a virtual tape manager 470 residing on the controller that accesses the 

pointers so as to determine the next consecutive one of the virtual tape volumes. 

Reference numerals added with respect to FIGS. 4 and 6, reproduced above. See also 
FIG. 5B, numerals 601 and 602. 

FIG. 6 illustrates a lookup table 600 having a volume management 
lookup table 601 and one or more data management lookup tables 602. The 
volume management table 601 manages an entire disk storage space 501 
(FIGS. 5B-C) spanning one or more disk drives. Each of the data management 
tables 602 manages a corresponding individual virtual tape volume 500 (FIGS. 
5A-C). The volume management table 601 has a virtual tape drive descriptor 
610, one or more virtual tape volume pointers 620 and a check sum block 630. 
... The pointers 620 contain the starting LBA of each data management 
table 602. 

Specification paragraph [0028]. See also Specification paragraph [0070] ("If the 
previous virtual tape volume was not the last volume 2335, then the next virtual data 
management table is loaded 2340.") 
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Keele does not disclose a volume management table that has pointers to the 
virtual tape volumes . Further, Keele does not disclose a virtual tape manager that 
accesses the pointers to determine the next consecutive virtual tape volume to load . 

With respect to canceled claim 2, the Office action equates a volume 

management table having pointers to the controller which "stores tape maps of the 

virtual tapes" and adds that the "tape map pointer points to a respective tape map." 

Office action page 5, paragraph 9. The Keele tape map, however, merely provides 

information regarding "BOT. EOT, IBG and TM" and "where the individual user records 

are stored on the disk." Keele column 44, lines 11-15. The Keele controller does not 

access either the tape map pointer or the tape map itself to determine a next 

consecutive virtual tape volume to be loaded into a (physical) optical disk drive. Rather, 

Keele teaches that each virtual tape to be loaded must be specified by the host 

computer or the operator, and the disk directory that manages those virtual tapes is 

required to be stored on a controller-based hard drive separate from the virtual tapes 

(stored on optical disk): 

When the host computer or an operator requests a certain volume serial number 
(VSN), MOST must determine which physical optical disk is required, its location 
and orientation. This requires that a disk directory be maintained by MOST. The 
disk director/ which keeps track of virtual tapes is stored on the Winchester hard 
drive 50. 

Keele column 35, lines 2-8. For all of the above stated reasons, claim 17 further 
patentably distinguishes Keele. 

Claim 18 cites: 

The virtual tape stacker according to claim 17 further comprising: 
a physical tape device 350 attached to the controller; 
a tape cartridge 840 loadable into the physical tape device, 
wherein a physical tape volume corresponding to the tape cartridge is 
integrated into the virtual tape volume storage rotation 800. 

Reference numerals added with respect to FIGS. 8A-B, reproduced above. See also: 
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As shown in FIG. 8A, one or more physical tape drives 350 may be 
incorporated into the virtual sequential stacker 800. The VTC 400 (FIG. 4) 
monitors any physical tape drive 350 that is present. If a physical tape cartridge 
is manually loaded into a tape drive 350 and it is "Write Protected," the virtual 
tape management 470 (FIG. 4) enables the application program 130 (FIG. 3) to 
access the tape data directly. The physical tape volume 840 automatically 
becomes part of the virtual tape volume storage rotation . 

Specification paragraph [0034]. 

Keele does not disclose a physical tape device or a physical tape volume 

integrated into a virtual tape volume storage rotation . With respect to canceled claim 3, 

the Office action equates the Keele optical disk and jukebox to a physical tape device, 

with the only justification that: "The function of the jukebox is to store disks in physical 

slots." Office action page 6, paragraph 9. The Keele optical disk drive, however, is not 

a physical tape device. The Office action continues this assertion: "Keele teaches . . . 

that the controller may have attached devices such as 3480 cartridge tape, 3420 reel 

tape . . ." Office action page 6, paragraph 9. This, however, is not what Keele 

discloses. Rather, Keele states that: 

The MOST controller is a software and microcode controlled device. This 
provides flexibility in that the controller together with it attached devices can 
emulate different standard channel attached devices (3480 cartridge tape, 3420 
reel tape . . .). 

Keele column 24, lines 13-17. That is, Keele teaches away from an attached physical 
tape device. See also Keele Fig. 1 which illustrates the MOST Controller does not 
attach to any physical tape device. Nowhere in Keele is there mention that the MOST 
Controller communicates with a tape storage device. Further, the Keele tape map 348 
(Fig. 5) and description thereof are entirely devoid of any mention of integrating physical 
tape volumes into a stacker arrangement of virtual tape volumes. That is, the Keele 
disclosure falls far short of reading on a physical tape volume that is integrated with 
virtual tape volumes as claimed. For the above stated reasons, claim 18 further 
patentably distinguishes Keele. 
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Claims 19-21 



Claim 19 cites: 

A virtual tape stacker method comprising: 

providing a plurality of virtual tape volumes 500 on a random access 
storage device 330; 

defining a virtual tape drive 610 in a volume management table 601 
located on the random access storage device; 

identifying the virtual tape volumes in a plurality of data management 
tables 602 located on the random access storage device; 

storing in the volume management table a plurality of pointers 620 to the 
data management tables so as to identify the location of the virtual tape volumes 
on the random access storage device; and 

predetermining an access order for the pointers so as to define a 
sequential order for loading the virtual tape volumes into the virtual tape drive in 
response to eject commands from a server. 

Reference numerals added with respect to FIGS. 4 and 6. 

Keele does not disclose defining a virtual tape drive or predetermining an access 
order for pointers , or defining a sequential order for loading the virtual tape volumes in 
the virtual tape drive. As argued with respect to claim 16, above, Keele does not 
disclose a virtual tape drive , much less a sequential order for loading virtual tape 
volumes int o a virtual tape drive . With respect to canceled claim 12, the Office action 
equates "said sequential order determined by a predetermined access order of said 
pointers" to a combination of optical disk "sectors which can be written and read 
sequentially" and a "system of pointers loaded in memory of the controller so that 
search operations can be quickly executed." Office action page 14, paragraph 18. 
Simply put, sequentially accessing physical sectors on an optical disk does not 
anticipate a sequential order for loading virtual tape volumes into a virtual tape drive. 
Likewise, pointers for quick search operations do not anticipate a predetermined access 
order for pointers that define that sequential loading order. 

Similarly, claim 19 patentably distinguishes Dailey, which, as argued above, does 
not disclose either a virtual tape drive or a plurality of virtual tape volumes, much less 
sequentiall y loading virtual tape volumes into a virtual tape drive in response to eject 
commands from a server . The second Office action refers to Dailey's library system. 
Second Office action page 4. Dailey's description of that system is terse: "the tape 
drive emulators may conform to . . . conventional tape drives that may readily be 
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inserted within a drive bay of library systems." Dailey paragraph [0085]. In this respect, 
Dailey teaches away from virtual tape volumes sequentially loaded into a virtual tape 
drive. Rather, Dailey discloses multiple tape drive emulators (controllers) integrated 
into a library system in lieu of conventional (physical) tape drives. 

As such, claim 19 patentably distinguishes both Keele and Dailey. Claims 20 
and 21, which depend from claim 19 are likewise not anticipated by Keele or Dailey. 
Claims 20 and 21 are not anticipated by Keele or Dailey for the additional reasons 
discussed immediately below. 



Claim 20 cites: 

The virtual tape stacker method according to claim 19 further comprising: 
reading one of the pointers 620 according to the access order; 
locating one of the data management tables 602 according to the read 
pointer; and 

addressing a next consecutive one 820 in the sequential order of the 
virtual tape volumes 500 according to the located one of the data management 
tables. 

Reference numerals added with respect to FIGS. 6 and 8A. See also 

The pointers 620 contain the starting LBA of each data management 
table 602. The check sum block 630 verifies the integrity of the volume 
management table data. 

As shown in FIG. 6, a data management table 602 has a virtual tape 
volume descriptor 640, a table descriptor 650, multiple table entries 660, an end 
of table 670 and a check sum block 680. The volume descriptor 640 stores 
LBAs corresponding to the virtual tape volume BOT and EOT 502, 504 (FIG. 
5A), an indication of the virtual tape volume status as full or empty, and the LBA 
of the start of the early warning zone. 

Specification paragraphs [0028]-[0029]. 



Keele does not disclose addressing a next consecutive virtual tape volume 

according to a located data management table . With respect to canceled claim 8, the 

Office action equated a similar limitation with: 

when a virtual tape is mounted, the tape map is read and if it has been altered, is 
written onto the disk ... the pointer to the tape map is recorded in the tape 
directory for each virtual tape as a way of accessing, reading and updating 
pointers every time a virtual volume is loaded on a disk. 
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Office action page 10, paragraph 13. As argued with respect to claim 17, above, the 
Keele controller cannnot access the tape map pointer or the tape map itself to 
determine what virtual tape is to be loaded into the (physical) optical disk drive. 
Further, all virtual tapes on a Keele optical disk are loaded into the disk drive at once. 
As such, claim 20 further patentably distinguishes Keele. 

Claim 21 cites: 

The virtual tape stacker method according to claim 20 further comprising: 
providing a physical tape volume 840 loaded on a physical tape device 
350; and 

integrating the physical tape volume in a storage rotation of the virtual 
tape volumes. 

Reference numerals added with respect to FIG. 8A. As argued above with respect to 
claim 18, Keele does not disclose a physical tape device or a physical tape volume 
integrated into a virtual tape volume storage rotation , and, as such, claim 21 further 
patentably distinguishes Keele. 
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Claims 22-24 



Claim 22 cites: 

A virtual tape stacker comprising: 

a plurality of virtual tape volumes configured on a random access data 
storage device; 

a virtual tape drive defined by a controller in communications with the 
random access data storage device; 

a virtual tape manager configured on the controller so as to transfer data 
between one of the virtual tape volumes loaded into the virtual tape drive and an 
application program, 

wherein the virtual tape manager indicates a sequential order for loading 
a next consecutive one of the virtual tape volumes into the virtual tape drive upon 
ejection of the loaded one of the virtual tape volumes. 



As argued with respect to claims 16 and 19, above, Keele does not disclose a 
virtual tape drive or a sequential order for loading the virtual tape volumes upon 
ejection . Also argued with respect to claims 16 and 19, above, Dailey does not disclose 
either a plurality of virtual tape volumes or a virtual tape drive , much less sequential 
order for loading the virtual tape volumes upon ejection . As such, claim 22 patentably 
distinguishes both Keele and Dailey. Claims 23 and 24, which depend from claim 22 
are likewise not anticipated by Keele or Dailey. Claims 23 and 24 are not anticipated by 
Keele or Dailey for the additional reasons discussed immediately below. 



Claim 23 cites: 

The virtual tape stacker according to claim 22 further comprising: 
a volume management table maintained in the virtual tape manager, 
a plurality of pointers to the virtual tape volumes stored in the volume 

management table, 

wherein the sequential order of loading the virtual tape volumes into the 

virtual tape drive is determined by an access order of the pointers. 

As argued with respect to claim 19, above, Keele does not disclose an access 
order for pointers or a seguential order for loading virtual tape volumes determined by 
the access order. As argued with respect to claim 16, above, Keele does not disclose a 
virtual tape drive , much less a sequential order for loading virtual tape volumes into a 
virtual tape drive . As such, claim 23 further patentably distinguishes Keele. 
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Claim 24 cites: 

The virtual tape stacker according to claim 23 further comprising: 
a physical tape volume, 

wherein a last one of the virtual tape volumes is previous to the physical 
tape volume in the sequential access order and a first one of the virtual tape 
volumes is next from the physical tape volume in the sequential access order. 

As argued above with respect to claim 18, Keele does not disclose a physical 
tape device or a physical tape in a sequential access order with virtual tape volumes . 
As such, claim 24 further patentably distinguishes Keele. 

With respect to canceled claim 14, the second Office action asserts that Dailey 
"discloses a tape drive emulator that contains conventional tape cartridges (physical 
volumes) and non-tape storage media (logical tape volumes) all stored within the same 
logical storage areas." Second Office action page 5. Applicants respectfully traverse 
that assertion. The term "volume" is used but once in Dailey. See paragraph [0075] 
("high-volume applications"). Indeed, as argued above, the Dailey data cartridge 
structure teaches away from a multiple tape volume structure. Although Dailey does 
describe a library system 70 (Fig. 10), nothing in the description discloses that the 
library system loads the data cartridges in any sort of order, much less an order that 
incorporates a last virtual tape volume previous to a physical tape volume or a first 
virtual tape volume next from a physical tape volume . As such, claim 24 further 
patentably distinguishes Dailey on these grounds. 
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Summary 

In light of the foregoing amendments and remarks, Applicants respectfully submit 
that claims 16-24 are in condition for allowance. Applicants request that these claims 
and this application be passed to issuance. If the Examiner believes that any issue 
remains that requires clarification, however, the Examiner is invited to call the 
undersigned attorney of record at the number indicated below. 



Respectfully submitted, 

LAW OFFICE OF GLENN R. SMITH 



Dated: // / /3 / ZO Q J, By: 




Glenn R. Smith, Esq. 
Registration No. 38,308 
Attorney of Record 
28626 Brookhill Road 
Trabuco Canyon, CA 92679-1163 
Telephone/Fax: (949) 709-7164 
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